I think a yaml format that can encode different types of rules/options for linting would be much more preferable than a custom / one-file-per-line format (that is limited to just that).

I also think that all/nothing for lint ignoring (per-file) is too coarse for the general case. Especially since many lint rules pertain (in Helm) to e.g. Chart.yaml (ref). Likely it normally would be better to exclude certain rules for Chart specific files (Chart.yaml, values.yaml (default values), etc), and paths for templates, etc. See https://github.com/helm/helm/tree/main/pkg/lint/rules for current Helm linting rules.

Also take e.g. https://yamllint.readthedocs.io/en/stable/configuration.html#configuration or https://ansible.readthedocs.io/projects/lint/configuring/#ansible-lint-configuration as inspirations/examples for what might go into a lint configuration (of course not every there will apply to Helm).

@GeorgeJ
I have a question about this comment:
I also think that all/nothing for lint ignoring (per-file) is too course for the general case. Especially since many lint rules pertain (in Helm) to e.g. Chart.yaml (ref). Likely it normally would be better to exclude certain rules for Chart specific files (Chart.yaml, values.yaml (default values), etc), and paths for templates, etc. See https://github.com/helm/helm/tree/main/pkg/lint/rules for current Helm linting rules.
In response this discussion about the broad approach to lint ignoring, especially for key Helm config files like Chart.yaml, I want to discuss the current errors handling from the PR that we submitted. Right now we remove errors rather than skipping them altogether
Here’s the gist:
Error removal: We let all errors get logged as usual but we remove them from the final error list that users see. This keeps the linting thorough but the user interface clean.
Debugging Option: If someone needs to dive deep or is troubleshooting, they can use the --debug flag to see everything, removed errors included.
Post-Processing Advantages: Handling the error list after it’s fully formed means we clean things up at the end. This makes managing exceptions way easier and ensures we’re not tossing useful feedback too early.
I see a few pluses here:
Flexible Error Reports: You get a neat, easy-to-digest error report by default but can switch to a detailed view when needed.
Better Troubleshooting: Keeping all the linting info till the end helps us understand what we're filtering out and why, making it easier to adjust if something's not quite right.
What you are suggesting would be more aligned with something like this :we would need to change the structure of the lintError variable to something like this:

type LintError struct {
 // Err is the original linter error
 Err error
 // ChartPath is the string path to the chart that generated this linter error
 ChartPath  string
 // TemplatePath is nullable because some errors are chart-level while others are template-specific
 TemplatePath *string
}

In this way we would be able to better review and analyze the errors and even list them in the output, giving an idea of how many errors are ignored, but that would require a pretty important lift, because it would change multiple files/potentially structures/functions

Reply from @gjenkins8

Morning, I don't disagree with the above (the "post-filtering" approach). I took a look at the reworked HIP, it looks good to me! Thanks for the updates
If the idea of specific rule based exclusions is too much for the moment, I think fine to pivot and just support what you have described (the fileMask and errorMask "directives")
I would suggest to small updates the HIP with some scope details:
only file / error based exclusions (masks) considered
rule-based exclusions (& configuration) considered difficult to implement, and skipped for the moment
My major/main goal was to make sure e.g. like yaml lint that the lint configuration can be extended in the future. I think it can with the current format (but I will put some comments on the format on the HIP)

perhaps a format more like (bikeshedding hard here):

# .helmlintconfig.yaml file example
pathIgnore:
- "migrations/templates/job.yaml"
- "gitlab/templates/shared-secrets/self-signed-cert-job.yml"
- "gitlab/templates/*.yaml"
errorIgnore:
- "chart metadata is missing these dependencies*"
- "<include 'fullname' .>"

I modified this section a little, but kept it similar to our suggestion because an error (the same error specifically) can occur in multiple charts / sub-charts, and connecting it to a file path would be beneficial (sorry for the bikeshedding here)

Providing rule specific excludes and configurations, and composing configuration from "default" configuration e.g. similar to https://yamllint.readthedocs.io/en/stable/configuration.html#extending-the-default-configuration

Helm today doesn't "name" its lint rules, and changing the code/structure to support the above can be extended later

Done, let me know if it's ok

oops, sorry, I mean we should add these to the "rejected ideas":

• Providing rule specific excludes (Helm today doesn't "name" its lint rules)
• composing configuration from "default" configuration (e.g. similar to https://yamllint.readthedocs.io/en/stable/configuration.html#extending-the-default-configuration)

glob patterns for both file paths and error strings

done !

Can we reword analogous to .gitignore or .helmignore now that we're targeting a general-purpose config file format?

done

Potential phrasing: this can put helm users in situations where imported subcharts are flagged with low-priority lint errors that they'd prefer to suppress

done

or wherever the env var says to look

done

n.b. this PR will need some significant changes to catch up with the current design as described here in HIP-0019

this i will leave untouched if it's ok with you, since we put the PR in draft

this piece is not self-evident to me, can we add a hypothetical such as "errorCode: H019 would allow for across-the board suppression of errors by error code. We are deferring this for now because it will require a refactor of all 50+ existing helm lint cases."

done

Looks like bullet points 1 and 3 here might be overlapping, maybe we could consolidate?

done

The proposed changes to the Helm linting system will likely require significant modifications

The basic design in this HIP won't dramatically alter the helm codebase, but pretty much all of the stretch goals here in "open issues" would require some broader helm refactors.

done

Hi Terry, Following our discussion with George, we've changed the .helmlintignore file to .helmlintconfig.yaml. The reason for this change is that the new config file will be in YAML format, and it will not only allow us to ignore specific linting errors but in the future we will also add more options/rules for linting. This is similar to the hadolint.yaml file that supports ignoring errors and setting up specific linting rules and options.

Also, We did put the PR for helm/helm back in Draft, since we are waiting to have a finalized version of the HIP to continue the development work on the helm repo. Please let me know If you have any additional reservation, and thank you for the review